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ABSTRACT 

Monitors  are  a valuable  tool  for  organizing  operations  on  shared 
data  in  concurrent  programs.  In  some  cases,  however,  the  mutually  ex- 
clusive procedure  calls  provided  by  monitors  are  overly  restrictive.  Such 
applications  can  be  programmed  using  shared  classes,  which  do  not  enforce 
mutual  exclusion.  This  paper  presents  a method  of  verifying  parallel  pro- 
grams containing  shared  classes.  One  first  proves  that  each  class  pro- 
cedure performs  correctly  when  executed  by  itself,  then  shows  that  simul- 
taneous execution  of  other  class  procedures  can  not  interfere  with  its 
correct  operation.  Once  a class  has  been  verified,  calls  to  its  procedures 
may  be  treated  as  uninterruptible  actions;  this  simplifies  the  proof  of 
higher-level  program  components.  Proof  rules  for  classes  and  procedure 
calls  are  given  in  Hoare's  axiomatic  style.  Several  examples  are  verified, 
including  two  versions  of  the  readers  and  writers  problem  and  a dynamic  re- 
source allocator. 

Index  terms;  program  verification,  program  proving,  concurrency,  parallel 
programs,  monitors,  classes,  operating  system  design,  shared  classes 


INTRODUCTION 


Verifying  concurrent  programs  is  complicated  by  the  nondeterministic  way  in  which 
parallel  processes  can  affect  each  other  through  operations  on  shared  variables. 
Several  language  features  for  governing  this  interaction  have  been  suggested:  the 
monitor,  (Hoare,  1974),  (Brinch  Hansen,  1973),  is  a particularly  valuable  tool.  A 
monitor  resembles  a Simula  class:  it  is  a set  of  variables  together  with  proce- 
dures that  operate  on  those  variables.  Monitors  have  three  restrictions  not  found 
on  classes:  1)  each  variable  in  a concurrent  program  must  belong  to  a monitor  or 
be  local  to  a process;  2)  monitor  variables  may  not  be  used  outside  the  monitor; 

3)  the  monitor  includes  scheduling  operations  that  prevent  two  processes  from  ex- 
ecuting monitor  procedures  at  the  same  time.  These  restrictions  provide  a syntac- 
tic guarantee  that  two  processes  can  not  simultaneously  operate  on  the  same  vari- 
able. Such  a guarantee  greatly  simplifies  the  proof  process.  However,  there  are 
cases  in  which  requirement  3 is  overly  restrictive.  For  example, 

1.  Some  operations  on  shared  variables  can  overlap  in  time  without  inter- 
ference. Examples  are  read  operations  and  operations  which  modify  dif- 
ferent parts  of  a shared  data  structure.  Even  operations  which  modify 
the  same  variables  may  do  so  in  a way  that  is  safe,  despite  simultane- 
ous execution. 

2.  Objects  which  are  syntactically  shared  may  in  fact  be  dynamically  al- 
located to  one  process  at  a time,  so  that  there  is  no  possibility  of 
interference. 

3.  Even  in  cases  where  each  procedure  requires  mutual  exclusion,  it  may 
be  useful  to  allow  the  programmer  to  implement  his  own  scheduling 
policy,  rather  than  binding  him  to  the  monitor's  standard  policy. 

Often  a shared  object  will  have  some  operations  that  fall  in  each  of  the  categor- 
ies above. 

This  paper  discusses  the  specification  and  verification  of  shared  data  classes,  a 
generalization  of  monitors  in  which  mutual  exclusion  is  not  automatically  provided. 

To  verify  a class,  one  must  show  that  the  procedures  operate  correctly  (according 
to  their  specifications)  even  when  executed  in  parallel.  The  verification  of  a 
process  which  uses  the  class  can  then  be  based  on  the  specifications  of  the  pro- 
cedures, without  regard  to  the  details  of  their  implementation. 

It  should  be  emphasized  that  the  intent  is  not  to  advocate  replacement  of  monitors 
by  shared  classes.  The  built-in  mutual  exclusion  in  monitors  is  a valuable  aid  to 
producing  correct  programs,  and  it  greatly  simplifies  correctness  proofs.  Shared 
classes  should  be  used  only  when  they  yield  significant  improvement  in  performance. 
In  such  cases,  extra  care  must  be  devoted  to  insuring  that  the  class  works  cor- 
rectly no  matter  how  its  actions  overlap  in  time;  the  proof  techniques  presented 
here  provide  a means  of  verifying  that  it  does. 

The  paper  is  organized  as  follows.  Section  2 reviews  the  axiomatic  proof  method 
and  provides  a basis  for  the  rest  of  the  paper.  The  syntax  of  shared  classes  is 
described  in  Section  3,  and  proof  rules  for  verifying  the  partial  correctness  of 
classes  and  processes  are  given  in  Sections  4 and  5.  Section  6 contains  a number 
of  examples.  Proofs  of  termination  are  discussed  in  Section  7.  Finally,  Section 
8 summarizes  and  evaluates  the  results. 


1 


consequence 


where  P f-  Q means  that 


2.  VERIFYING  CONCURRENT  PROGRAMS 

The  verification  techniques  in  this  paper  are  based  on  Hoare's  axiomatic  system 
for  proving  sequential  programs  (Hoare,  1969)  and  on  a method  for  verifying  paral- 
lel programs  developed  independently  by  Lamport  (1977)  and  the  author  (Owicki  and 
Gries,  1976).  A brief  review  is  given  here. 

Hoare's  method  is  concerned  with  partial  correctness.  The  partial  correctness  of 
a statement  S is  expressed  by  the  formula  {P}S{Q},  where  P and  Q are  as- 
sertions. {P}S{Q}  implies  that  if  execution  of  S begins  with  P true,  then  it 
either  ends  with  Q true  or  never  ends  at  all.  Hoare  provides  a set  of  axioms 
and  inference  rules  for  proving  partial  correctness.  For  example, 

assignment  {P^}x:=E{P},  where  P^  is  the  assertion  formed  by 

replacing  every  free  occurrence  of  x in  P by  E 

{P'}S{Q'},P  |-P',Q'  hQ.  o I n 

consequence  where  P f-  Q means  that 

{P}S{Q} 

Q can  be  proved  using  P as  an  assumption,  and 
the  notation  ^ means  that  b can  be  deduced  if 
a has  been  proved. 

A program  proof  can  be  presented  informally  by  giving  a proof  outline,  in  which 
assertions  are  displayed  at  appropriate  points  in  the  program.  This  style  is  used 
in  the  examples  in  this  paper.  In  a proof  outline,  each  statement  S is  always 
directly  preceded  by  one  assertion,  called  its  pre-condition  or  pre(S).  Suppose 
{P}S{Q}  has  been  proved, and  T is  a statement  in  S,  Then,  if  execution  of  S 
begins  with  P true,  pre(T)  holds  whenever  T begins  execution. 

Concurrent  execution  is  initiated  by  a statement  with  the  form 

cobegin  Si  //  $2  //  . . . //  Sn  coend. 

The  statements  Si,...,Sn  are  called  parallel  processes.  There  are  no  restric- 
tions on  the  way  in  which  parallel  execution  is  implemented;  in  particular,  nothing 
is  assumed  about  the  relative  speeds  of  the  processes.  It  is  required,  however, 
that  each  assignment  statement  or  expression  evaluation  represent  a single  uninter- 
ruptible action.  This  rule  can  be  relaxed  when  no  ambiguity  results.  For  example, 
the  statement  x :=x+l  can  be  treated  as  uninterruptible  if  x is  a local  pro- 
cess variable,  but  not  if  x is  shared  between  processes.  Actions  which  may  safely 

be  treated  as  uninterruptible  are  called  elementary.  The  proof  rule  for  shared 
classes  in  Section  4 gives  conditions  under  which  a procedure  call  may  be  treated 
as  an  elementary  action,  even  though  it  is  in  fact  an  interruptible  sequence  of 
actions  on  shared  variables. 


The  proof  rule  for  cobegin  statements  is 


^ . {Pi}Si{Qi},. . . .{PnlSnCQ-}  are  interference-free 

cobegin 

{Pi  A ...  A P^}  cobegin  Si  //  . . . //  Sp  coend  {Qi  A . . . A Qp) 

The  rule  states  that  the  effect  of  executing  Si,...,Sn  in  parallel  is  the  same 
as  executing  each  one  by  itself,  provided  the  processes  do  not  "interfere"  with 
one  another.  To  show  that  they  do  not,  one  must  prove  that  certain  key  assertions 
in  the  proof  of  {Pi}Si{Qi}  remain  true  under  parallel  execution  of  the  other 
processes.  In  this  case,  the  proof  of  {PilSilQi*}  will  still  hold,  and  Qj  will 
be  true  on  termination  of  Si  if  Pi  was  true  on  initiation.  For  example,  the 
assertion  (a^b)  remains  true  under  execution  of  b:=b+l,  while  the  assertion 
(b=0)  does  not.  The  invariance  of  an  assertion  P under  execution  of  a state- 
ment S is  expressed  by  the  formula  (P A pre(S)}S{P}.  This  is  the  basis  of  the 
interference-free  property  defined  below. 

Definition.  Given  a proof  {P}S{Q}  and  a statement  T with  precondition  pre(T), 
T does  not  interfere  with  {P}S{Q}  if  the  following  formulas  can  be  proved. 

a)  {QApre(T)}T{Q} 

b)  Let  S'  be  any  statement  in  S except  a component  of  an 
elementary  action. 

Then  {pre(S' ) A pre(T)}T{pre(S' )}. 

Definition.  {PilSiIQi},. . . ,{Pn}Sn{Qp}  are  i nterference-f ree  iff  for  each  elemen- 
tary action  T in  S^,  T does  not  interfere  with  {Pj}Sj{Qj}  for  jf  i.  (Of 
course,  local  variables  of  Si  may  be  renamed  to  avoid  conflict  with  variables  of 
Sj.) 


It  can  be  proved  that  when  the  cobegin  rule  is  used,  any  computation  that  begins 
in  a state  with  PiA...APp  satisfied  has  the  property  that  pre{S)  holds  when- 
ever S is  ready  to  execute.  This  is  because  the  sequential  proof  of  the  process 
containing  S guarantees  that  pre(S)  will  hold  at  the  instant  S becomes  ready 
to  execute,  and  the  interference-free  test  insures  that  it  will  remain  true  in 
spite  of  the  actions  of  other  processes. 

At  times  it  is  necessary  to  add  statements  containing  auxiliary  or  ghost  variables 
in  order  to  verify  a cobegin  statement.  The  auxiliary  variable  should  be  used 
only  in  assignments  to  each  other,  so  that  their  presence  does  not  affect  the  pro- 
gram's control  flow  or  its  effect  on  non-auxiliary  variables. 

The  use  of  the  cobeqin  rule  and  auxiliary  variables  is  illustrated  by  verifying 
the  program 

Add2 : cobegin  x:=x  + l//x:=x  + l coend, 

under  the  assumption  that  x:=x  + l is  an  uninterruptible  operation.  Proving 
{x = 0}Add2{x = 2}  requires  the  addition  of  an  auxiliary  variable  y.  A proof  out- 
line for  the  augment^  program  is  given  below. 
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{x  = 0} 
y :=  0; 

{x  = yAy  = 0) 
cobeqin 

ur=y}  X :=x  + l {x=y  + l} 

// 

{y  = 0}  [x  :=  X + 1 ; y :*  1]  {y  = 1 } 
coend 

{x  = y+  1 Ay  = 1} 

{x  = 2} 

Here  the  notation  [x  ;= x + 1 ; y ;=  1]  indicates  an  elementary  action;  assignments 
to  auxiliary  variables  can  always  be  included  in  an  elementary  action  because  they 
take  no  "real"  execution  time.  The  sequential  proof  of  each  process  is  trivial. 
The  interference-free  test  requires  four  steps,  which  show  that  each  assertion  in 
one  process  remains  true  under  the  action  in  the  other  process.  For  example,  to 
show  that  (x  = y)  is  invariant  under  [x  :=  x + 1 ; y :=  1],  one  must  prove 

{x  = y Ay  = 0}  X :=  X +1 ; y :=  1 {x  =y}, 

which  is  trivial. 

3.  SYNTAX  OF  SHARED  CLASSES 

A shared  class  closely  resembles  a monitor.  It  defines  a set  of  variables,  pro- 
cedures which  operate  on  the  variables,  and  an  initialization  statement.  The  class 
variables  may  not  be  referenced  outside  the  class  itself.  Execution  of  class  pro- 
cedures by  different  processes  may  overlap  in  time:  this  is  the  major  difference 
between  classes  and  monitors. 

As  an  example,  consider  the  class  type  Counter  defined  by  the  declaration  below. 

type  Counter.'class; 

begin  var  c: integer;  mutex: semaphore; 
procedure  Add(y:integer) ; 
begin  var  t: integer; 

wait(mutex);  t : = x ; x :=  t + y;  signal  (mutex) end; 
procedure  Sub (y: integer); 
begin  var  t: integer; 

wait  (mutex) ; t:  = x;x  :=  t-y;  signal  (mutex)  end; 
begin  x :=  0;  mutex  :=  1 end 
end  Counter 

An  instance  of  the  class  is  created  by  the  declaration 
var  C:Counter, 

and  the  class  procedures  are  then  invoked  by  the  statements  C.Add(i)  and 
C.Sub(i ). 

A few  comments  on  the  example  are  in  order.  The  class  procedures  are  written  in 
terms  of  elementary  actions;  thus  incrementing  x requires  two  steps.  Semaphores 

are  used  for  synchronization  here  and  throughout  the  paper,  but  the  proof  tech- 

niques to  be  developed  are  independent  of  the  particular  synchronization  method. 
Note  that  Counter  is  essentially  a monitor,  since  each  procedure  uses  mutex 
to  obtain  exclusive  access  to  the  shared  variable  x.  Later  examples  will  illus- 
trate other  kinds  of  classes. 

Several  additional  syntax  restrictions  are  necessary  for  the  proof  methods  pre- 
sented later.  First,  each  variable  used  inside  a cobegin  statement  must  be  de- 
clared inside  a class  or  a process.  This  simplifies  the  interference-free  test, 
since  a process  variable  can  not  be  modified  by  an  action  of  another  process,  and 

a class  variable  can  only  be  changed  in  a class  procedure.  For  similar  reasons,  a 

shared  class  variable  may  not  be  passed  as  an  actual  parameter  to  a procedure  in 
another  class,  since  this  would  complicate  the  interference-free  test  for  that 
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class.  In  addition,  the  actual  var  parameters  in  a procedure  call  must  be  dis- 
tinct from  each  other  as  well  as  from  the  value  parameters;  this  restriction  is 
needed  for  Hoare's  procedure  call  rule  (Hoare,  1971). 

Lastly,  it  must  be  possible  to  partition  the  class  variables  into  control  and  data 
variables.  The  control  variables  are  used  for  synchronization,  and  are  invisible 
outside  the  class  in  the  sense  that  they  do  not  appear  in  its  specifications. 

Each  class  procedure  body  has  the  form 

begin  declarations;  enter;  operate;  exit  end, 

where  the  enter,  exit  and  operate  sections  satisfy  the  following  conditions. 

1.  enter  and  exit  are  elementary  actions,  and  operate  is  composed 
of  elementary  actions  (a  procedure  call  to  a previously-verified 
class  is  elementary). 

2.  enter  and  exit  do  not  use  (read  or  write)  any  data  variables,  and 
they  call  only  locally-defined  classes. 

3.  operate  does  not  use  any  control  variables. 

In  the  class  Counter,  x is  a data  variable  and  mutex  is  a control  variable; 
the  enter  and  exit  actions  are  wait(mutex)  and  signal (mutex). 

Condition  1 prohibits  class  procedures  from  calling  each  other.  Nonrecursive 
calls  could  be  handled  by  in-line  expansions  of  the  procedure.  Allowing  recursive 
calls  is  possible,  but  would  require  a stronger  proof  rule  than  che  one  in  Section 
5. 

Any  procedure  trivially  satisfies  conditions  2 and  3,  since  enter  and  exit  can 
be  null  statements.  However,  class  verification  is  usually  impossible  unless 
enter  includes  all  the  synchronization  required  to  lock  out  procedures  which 
could  interfere  with  the  operate  section.  Thus  conditions  2 and  3 effectively 
prevent  the  operate  section  from  containing  a monitor-like  wait  which  releases 
the  mutual  exclusion  lock.  In  most  monitors,  wait  and  signal  occur  at  the  begin- 
ning and  end  of  procedures,  so  this  requirement  is  not  too  restrictive. 

4.  CLASS  SPECIFICATIONS 


Class  specifications  describe  the  visible  characteristics  of  a class,  including 
the  initial  values  of  data  variables  and  the  effect  of  each  procedure  on  data  vari- 
ables and  yar  parameters.  A class  invariant,  which  gives  the  relation  between 
control  and  data  variables,  is  used  in  proofs  only  inside  the  class  itself.  The 
components  of  the  specifications  for  a class  C are  listed  below;  the  program 
variables  which  may  appear  free  in  each  assertion  are  indicated  in  parentheses. 

C. Initial  (C.data) 

C. I (C. data, C. control)  (the  class  invariant) 

For  each  procedure  C.p(var  x;y) 

C. p. Pre( C. da ta,x,y, caller) 

C. p. Post (C. da ta,x.y, caller) 

C.p.Change(C.data)  (the  set  of  data  variables  changed  by  C.p), 
where  caller  is  the  identity  of  the  process 
which  invoked  C.p,  implicitly  passed  as  a value  parameter. 

The  specifications  for  class  Counter  of  Section  3 are 

Counter. Initial : x = 0 
Counter. I:  0£mutex£l 

Counter. Add. Pre:  x = Xo  Counter. Add. Post:  x = Xo+y 

Counter. Add. Change:  {x} 

Counter. Sub. Pre:  x = Xq  Counter. Sub. Post:  x = Xo  - y 

Counter. Sub. Change:  (x) 
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Verification  of  class  specifications  is  accomplished  using  the  two-step  method  de- 
scribed in  Section  2.  The  restrictions  on  variables  in  the  clauses  of  the  speci- 
fications limit  the  scope  of  the  interference-free  test  in  the  proof. 

Sequential  correctness 

1.  {true}  initialization  (C. Initial  AC.I} 

2.  For  each  procedure  C.p, 

(C.p.Pre  A C.I)  body  of  p (C.p.Post  A C.I) 
where  for  each  statement  S in  the  body  of  p,  pre{S)  f-C.I. 

3.  For  each  procedure  C.p,  the  set  C.p. Change  contains  all  data  variables  that 
appear  on  the  left-hand-side  of  assignments  in  C.p,  and  all  variables  in 

D.q. Change  for  each  procedure  D.q.  called  in  the  operate  part  of  C.p. 

Interference 

4.  For  each  pair  of  procedures  C.p  and  C.q,  including  p = q,  the  proofs  in  2 
above  are  interference-free,  except  possibly  for  the  initial  and  final  asser- 
tions C.p.Pre A I and  C.p. Post  A I. 

5.  If  C contains  a call  to  a class  D not  local  to  C,  then  each  assertion  P 
in  the  proof  of  C is  invariant  over  actions  of  D,  i.e.  for  all  D.r 

{D.r.PreAP}  D.r(var  a;  e)  {P} 

Verifying  the  specifications  in  this  way  assures  the  C.I  holds  at  all  times  {ex- 
cept possibly  during  elementary  actions,  which  effectively  take  no  time).  In  addi- 
tion, if  C.p.Pre  is  true  at  the  instant  when  C.p. enter  begins  execution,  it 
can  be  shown  that  C.p.Post  must  hold  at  the  instant  (if  any)  when  C.p. exit 
terminates.  When  C.p  executes  by  itself,  the  sequential  correctness  proof  im- 
plies that  it  performs  correctly.  The  interference- free  tests  cover  every  action 
which  could  interfere  with  C.p  by  modifying  a shared  variable.  All  shared  vari- 
ables belong  to  a class  and  can  only  be  modified  in  class  procedures.  Step  4 in 
the  proof  checks  all  actions  in  class  C and  (implicitly)  all  classes  local  to 
C.  Since  the  specifications  of  C contain  only  local  variables,  global  variables 
can  appear  in  assertions  in  C only  as  a result  of  a class  call.  Thus  step  5 
checks  all  global  classes  whose  variables  could  appear  in  the  proof  of  C.  Be- 
cause C.p.Pre  and  C.p.Post  do  not  have  to  pass  the  interference-free  test,  it 
is  necessary  to  assume  that  C.p.Pre  holds  at  the  instant  when  execution  begins, 
and  C.p.Post  is  not  guaranteed  to  hold  beyond  the  instant  of  termination.  This 
will  be  discussed  further  in  Section  5. 

To  illustrate  the  proof  method,  the  class  Counter  is  verified  below.  An  array 
of  auxiliary  variables 

var  m;  array  processid  of  0. . 1 

has  been  added  to  give  a stronger  invariant. 

Counter. I;  O^mutexil  A mutex  = 1 - ( i m[i]  ) 

processid 


Sequential  correctness 

1.  (true)  X :=  0;  mutex  :=  1 ; m :=  0 (x  = 0 A Counter.  1} 


2.  {x  = xo  A Counter.  1} 

[wait(mutex);m[caller]  :=1] 

{x  = Xfl  A m[cal ler]  = 1 A Counter.  1} 
t :=  x; 

{t  = Xo  Am[caller]  = 1 A Counter.  I } 

X :=  t + y; 

{x  = Xo  + y Am[caller]  = 1 A Counter. 1} 

[signal  (mutex) ; ni[cal  ler]  :=  0] 

{x  = Xo  + y A Counter. 1} 

A similar  proof  can  be  carried  out  for  Counter. Sub. 

3.  Both  procedures  change  x and  no  other  data  variables,  so  Add. Change  and 
Sub. Change  are  correct. 

Interference 

4.  The  interference-free  property  for  Counter  comes  from  the  mutual  exclusion 
provided  by  the  semaphore  operations.  In  general,  if  statements  S and  S' 
are  mutually  exclusive,  a proof  outline  can  be  found  in  which 

pre(S)  A pre(S' ) |-  false. 

Then  the  invariance  of  pre(S')  under  S follows  immediately,  for  the 
test  reduces  to 

{false} S {pre(S')} 

and  (false) T{P}  can  be  proved  for  any  T and  P.  In  the  class  Counter, 
for  example,  the  assertion 

P:  X = Xo  A m[caller]  = 1 A Counter . I 

must  be  proved  invariant  under  execution  of  x :=t+y  by  another  process. 

The  formula  to  be  proved  is 

(PA  pre(x  :=  t + y )}  X :=  t +y  {P}. 

Now  renaming  caller  to  caller'  in  P gives 

P A pre(x:=  t + y)  f-  I A m[caller]  = 1 A m[caller']  = 1 

where  caller  ^ caller'.  Then 

P A pre(x  :=  t+y)  |-  mutex £-1  A mutex  >0 
|-  false 

Thus  the  statements  are  mutually  exclusive,  and  the  interference-free  property 
must  hold.  The  pre- and  post-conditions  of  Add  and  Sub,  which  are  not  protected 
by  mutual  exclusion,  are  not  required  to  pass  the  interference-free  test. 

5.  No  verification  is  required  here,  since  Counter  does  not  call  any  other 
classes. 

5.  CLASS  PROCEDURE  CALLS 

Once  a class  has  been  verified,  programs  using  the  class  may  safely  treat  calls  to 
class  procedures  as  elementary  actions.  From  this  viewpoint,  a call  to  procedure 
C.p  is  equivalent  to  a nondeterministic  assignment  statement  thatgivesnew  values 
to  the  variables  in  C.p. Change.  The  new  values  must  satisfy  C.p. Post,  but 
otherwise  are  unconstrained.  The  obvious  proof  rule  for  such  an  action  is 

(C.p. Pre)  C.p (C.p. Post}. 

However,  this  rule  is  not  adequate.  The  proof  of  a process  that  calls  C.p  must 
pass  the  interference  test,  so  the  pre-condition  of  C.p  (like all  pre-conditions) 
must  be  invariant  under  the  execution  of  other  processes.  Frequently  the  asser- 
tion C.p. Pre  will  not  be  acceptable.  The  proof  rule  below,  a combination  of 
Hoare's  procedure  call  rule  and  rule  of  adaptation  (Hoare,  1971),  can  be  used  to 
obtain  a pre-condition  which  is  interference-free. 
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Class  procedure  call : Let  C be  a class  with  specifications  as  described  in  Sec- 
tion 4.  Then  in  process  i 

f3k(C.p.Pre'  A V b (C.p.Post ' D Q) )}  C.pfl;?)  {Q} 

where  a = actual  var  parameters 
«■=  actual  value  param^eters 

C.p.Pre'=C.p.Prcf|“Y''' 

C.p.Post'  > C.p.Post  1 1 

is  any  assertion  _ _ 

k = variables  free  in  C.p.Pre’  or  C.p.Post',  but  not  in  a,  e,  Q, 

_ or  the  class  variables  of  C 
b = FuC.p. Change 

The  rule  of  adaptation  in  sequential  programs  is  discussed  in  Guttag,  et  al.(1977). 
For  concurrent  programs,  it  can  be  justified  as  a derived  proof  rule.  For  if 
{P}S{Q}  can  be  proved  using  the  class  call  rule,  it  can  also  be  proved  by  expand- 
ing procedure  calls  in-line  and  using  the  techniques  of  Section  2.  Details  are 
given  in  the  Appendix. 

In  most  cases,  the  formulas  proved  using  the  class  call  rule  can  also  be  derived 
informally  by  treating  the  procedure  call  as  a nondetermini stric  assignment.  This 
view  is  legitimate  for  partial  correctness,  but  not  for  termination.  An  assign- 
ment statement  always  terminates,  but  class  procedures  may  loop  c.'  become  blocked 
at  a synchronization  operation.  Section  7 discusses  methods  of  proving  termina- 
tion for  class  procedures  and  parallel  programs. 

As  an  example  of  the  use  of  the  class  call  rule,  consider  a proof  of 

{x  = t}  Counter. Add(l ) {x  = t + 1 }. 

Application  of  the  call  rule  gives 

{3xo(x  = Xo  A V x(x  = Xo+1  ^ X = t+1 ))}  Counter.Add(l  ){x  =t  + 1 }. 

Since  (x  = t)  (3xo(x  = Xq  A V x(x  = Xo+1  o x = t+1 ))),  the  rule  of  consequence  yields 

{x  = t}  Counter. Add(l ) {x  = t + l}. 

The  class  call  rule  allows  the  original  pre-  and  post-conditions,  x=Xo  and 
x = Xo  + l,  to  be  "adapted"  to  x=t  and  x = t + l.  Thus  the  value  of  x can  be 
related  to  a program  variable  rather  than  the  artificial  constant  xo.  More  im- 
portant, the  new  pre-condition  may  be  invariant  under  the  actions  of  other  pro- 
cesses where  the  old  was  not.  This  is  illustrated  in  the  proof  outline  below  (the 
program  is  essentially  the  example  of  Section  2). 

{x  = 0} 
t :=  0; 

{x  = tAt  = 0} 

CO beg in 

{)r=  t}  Counter. Add(l ) {x  = t + 1 } 

// 

(t  = 0} [Counter. Add (1 ) ; t :=  1]  {t  = 1 } 
coend 

The  formulas  for  both  calls  to  Counter. Add(l ) are  proved  using  the  class  call 
rule,  as  are  the  four  interference  tests.  For  example,  to  prove  that  x = t is 
invariant  under  [Counter.Add(l ) ; t :=1],  one  must  prove 

{x  = t A t = 0} [Counter. Add(l ) ; t : = 1 ] {x  = t} , 

which  requires  another  use  of  the  class  call  rule. 
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6.  EXAMPLES 

This  section  presents  several  examples  of  shared  classes  and  discusses  the  main 
points  in  their  verification. 

Example  1 . Monitor-like  classes  where  all  procedures  are  mutually  exclusive  are 
proved  by  first  verifying  the  enter  and  exit  actions.  Once  mutual  exclusion  is 
established,  the  interference  test  is  trivial.  In  Section  4,  the  class  Counter 
was  verified  using  this  method.  The  most  common  reason  for  using  a monitor-like 
class,  rather  than  a monitor,  is  to  provide  a special-purpose  scheduler. 

Hoare’s  proof  rules  for  monitors  include  an  invariant  J;  J holds  when  no  pro- 
cesses are  executing  monitor  procedures.  Such  a monitor  invariant  is  a special 
case  of  the  class  invariant.  For  example,  if  mutual  exclusion  is  accomplished 
with  a semaphore  mutex,  and  J is  a monitor  invariant,  then  (mutex  = 1 ^ J) 
is  an  equivalent  class  invariant.  Hoare's  proof  rules  for  monitors  can  be  derived 
from  the  class  rules,  but  only  for  monitor  procedures  which  fit  the 
enter ;operate;exit  pattern. 

Example  2.  A class  for  managing  a dynamically  allocated  resource  needs  procedures 
for  acquiring  and  releasing  a resource  unit,  as  well  as  the  usual  procedures  for 
operating  on  it.  A process  first  executes  Acquire,  then  some  sequence  of  oper- 
ations, then  Release.  Acquire  and  Release  require  mutual  exclusion,  but  re- 
source operations  do  not;  they  have  null  enter  and  exit  actions.  The  declara- 
tion below  shows  the  important  features  of  such  a class. 

type  Alloc:  class; 

begin  var  Resource;  array  unitid  of  resource; 
free:  powerset  of  unitid; 
f reeCount , mutex : semaphore ; 
owner:  array  unitid  of  processid; 
a,b.  auxiliary  integer; 

procedure  Acquire(var  unit:  unitid); 
begin  [wait(freeCount) ; a:=a  + l] 
wa  it (mutex ) ; 

unit  :=  oneof(free) ; owner[free]  :=  caller; 

[free  :=  free  ~ {unit} ; a :=  a - 1] 
signal (mutex) 
end 

procedure  Release(unit:  unitid); 

begin  if  owner[unit]  + caller  then  return; 
wait(mutex) ; 

[free  :=  free u {unit} ; b:=b+l] 
owner[free]  :=  null ; 
signal (mutex) ; 

[signal  (freeCount) ; b:=b-l] 
end 

procedure  opl(unit:  unitid,...); 

begin  operate  on  Resource[unit]  end 

procedure  op2. . . * 

begin  free  :=  allUnits;  freeCount  :=  unitCount; 

owner  :=  null ; a :=  0;  b ;=  0 
end 

end  Alloc 

The  control  variables  of  Alloc  are  mutex  and  freeCount;  the  other  variables 
are  data  variables.  Alloc  is  specified  as  follows: 
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Initial:  free  = all  Units  A owner  = null  Aa  = b=0 

I:  (Vie unitld(i  e free  3 owner[i]  = null ) A freeCount  = size(free)  + b - a 
A 0 <.  freeCount  <.unitCount) 


Acquire.Pre:  true 

Acquire. Change:  {free, owner, a} 

Release. Pre:  owner[unit] = caller 
Release. Change:  (free, owner, b} 

opl.Pre:  owner[unit]  = caller  A .. . 
opl. Change:  {Resource[unit]} 

op2.Pre:  owner[unit]  = caller  A .. . 
op2. Change:  {Resource[unit]} 


Acquire  Post:  owner[uni t] = cal ler 


Release.  Post:  unite  free 


opl. Post:  owner[unit]  = caller  A ... 
op2.Post:  owner[unit]  = caller  A ... 


The  sequential  step  in  the  class  verification  is  quite  straightforward.  The  in- 
terference-free proof  involves  four  cases. 

1.  {Acquire, Release}  under  {Acquire, Release} : mutual  exclusion  provided  by 
mutex. 

2.  {Acquire, Release}  under  {opl,op2}:  opl  and  op2  do  not  modify  any 
variables  needed  in  assertions  of  Acquire  or  Release. 

3.  {opl,op2}  under  {Acquire, Release} : the  only  variable  used  in  opl  or  op2 
and  modified  in  Acquire  or  Release  is  owner[unit].  The  pre-condition 
of  ach  action  in  opl  or  op2  should  include  owner[unit] = ca.ler.  Now 
Acquire  only  changes  owner[i]  when  owner[i] = null ; Release  only 
changes  owner[i]  when  ownerfi] = cal ler' , where  caller f caller’ . Thus 
neither  will  change  owner[unit]  while  opl  or  op2  is  being  executed. 

4.  {opl,op2}  under  {opl,op2}:  Suppose  opl  and  op2  are  executed  at  the 
same  time.  Let  owner[unit] = caller  in  opl  and  owner[unit'] = caller' 

in  op2;  then  caller f caller' . Thus  unit f unit',  and  the  two  procedures 
are  operating  on  different  resource  units. 

Example  3.  Many  search  table  organizations  allow  searches  to  go  on  in  parallel 
with  each  other  and  with  the  addition  of  a new  entry.  The  specifications  of  such 
a table  manager  are  given  below.  The  table  stores  keys  in  a data  structure  T. 
The  form  of  T is  not  important,  but  the  entries  are  indexed  in  some  way,  and 
select(T,i)  retrieves  the  entry  with  index  i.  Maxsize  gives  the  maximum  num- 
ber of  entries  in  T,  and  size(T)  gives  the  current  number. 

type  table:  class 

begin  var  T:  tabletype; 

Initial : Size(T) = 0 

I:  size(T)£Maxsize  A Vi  ,j(Select(T,i)  = Select{T,j)D  i = j) 

procedure  Insert(x:  key,var  i:  Tindex); 

Insert. Pre:  T = To  Asize(T)  < Maxsize  A '.'i( select (T,i ) f x) 

Insert. Post;  extend(T,To ,x) A select(T,i}  = x,  where 

extend(T,To,x)  = 3 i(select{T,i)  = x A select(To,i)  =null 
A V j(i  f j Dselect(T,j)  = select(To  ,j ) ) ) 

Insert. Change:  {T} 

procedure  Search(x:  key;vdr  i:  Tindex); 

Search. Pre:  T = To 

Search. Post:  (i  f null  DSelect(  f.i)  = x)  A 

(i  = null  3 V j(Select(To  ,j)  f x)) 

Search.  Change  = 4> 

The  specifications  for  Search  imply  that  x will  be  found  if  it  was  in  T 
when  Search  began.  If  it  was  added  later,  it  may  or  may  not  be  found. 


A', 


r 

[ 

I The  code  for  procedures  Search  and  Enter  is  not  given;  presumably  sequential 

I verification  is  possible.  For  parallel  execution.  Search  can  not  interfere  with 

L either  Search  or  Insert,  since  it  does  not  modify  any  shared  variables.  In 

I most  cases,  parallel  Inserts  would  not  be  safe,  so  Insert  must  include  code  to 

* lock  out  other  Inserts.  To  avoid  interference  with  Search,  Insert  should  be 

^ written  in  such  a way  that  the  assertion  (T  = To  V extend(T,To,x)  ) holds  after 

i each  action;  this  will  guarantee  that  Search  and  Enter  are  interference-free. 

f Example  4.  Lamport  (1977)  presents  an  interesting  pair  of  database  operations  to 

' show  that  elementary  actions  (to  use  the  terminology  of  this  paper)  are  not  neces- 

) sarily  sequential.  In  his  example,  operations  p and  q give  different  (correct) 

■ results  depending  on  whether  execution  of  p precedes,  follows,  or  overlaps  exe- 

i cution  of  q.  Thus  if  p and  q occur  in  parallel,  the  resulting  state  is  dif- 

I ferent  from  one  which  could  be  reached  by  p;q  or  q;p.  It  is  still  possible, 

|i  however,  to  specify  and  verify  the  correct  behavior  of  p and  q as  elementary 

actions. 

f Example  5.  The  well-known  readers  and  writers  problem  involves  a file  which  must 

be  synchronized  so  that  read  operations  can  occur  in  parallel,  but  a write  opera- 
tion blocks  both  reads  and  writes.  Several  solutions  have  been  published,  e.g. 
Courtois,  et  al . (1971),  Brinch  Hansen  (1972).  Here  we  show  how  such  a file  can 
I be  represented  and  specified  as  a class. 

f type  rwfile:  class; 

begin  var  f:  array  l..filesize  of  f record; 

reading : auxiliary  array  processid  of  0. .1 ; 

writing:  auxiliary  array  processid  of  0..1; 

1 ...synchronization  variables... 

^ Initial:  V i e processld(reading[i] = writing[i] = 0) 

j I:  (tnax(reading[i]  ) = 0 V Z writing[i]  = 0)  A Zwriting[i ] < 1 

procedure  startread; 

i startread. Pre:  reading[cal ler] = 0 

startread. Post:  reading[cal ler] = 1 
startread . Change : {readi ng[cal 1 er] } 

procedure  endread; 

endread.Pre:  readi ng[cal 1 er] = 1 
endread. Post:  reading[caller] = 0 
endread. Change:  {reading[caner]} 

procedure  startwrite; 

startwrite.Pre:  writing[caller]  = 0 
startwrite. Post:  writing[caller] = 1 
startwri te . Change : (wr i ti ng[ca 1 1 er] } 

procedure  endwrite; 

endwrite.Pre:  writing[cal ler] = 1 
endwrite. Post:  writing[caller] = 0 
endwri te . Change:  {wr i t i ng[cal 1 er] } 

procedure  read(i:  1 . .filesize;  var  x:  frecord); 
begin  x :=  f[i]  end 

read. Pre:  readingtcaller]  = 1 read. Post:  x = f[i] 

read. Change: 

procedure  write:  (i:  1.. filesize;  x:  frecord); 
begin  f[i]  :=  x er^ 

wr  i te.  Pre : writing  [cal  ler]  = 1 write. Post:  f[i]  = x 
wri te. Change:  {f[i]} 
begin  reading  :=  0;  writing  :=  0 end 
end  rwfile 


I 
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Procedures  startread  ...  endwrite  can  be  taken  from  any  of  the  solutions  to 
the  problem.  Their  correctness  is  assumed.  Sequential  proofs  for  read  and 
virite  are  trivial.  For  the  interference-free  proof,  one  must  first  show  that 
startread  ...  endwrite  can  not  interfere  with  read  by  changing 
reading[caller].  This  is  easy,  since  startread  and  endread  only  change 
reading[caller'],  where  cal ler f cal ler ' , and  startwrite  and  endwrite  do 
not  change  reading  at  all.  The  proof  for  write  is  similar.  For  the  various 
pairs  of  read,  write  operations,  the  interference  tests  are  passed  as  follows. 

read/read:  no  shared  variable  modified  in  read 

read/write:  mutual  exclusion  is  implied  by  the  invariant 
{max(reading[i])  = 0 V Ewriting[i]=  0) 

write/write:  mutual  exclusion  is  implied  by  the  invariant 
(E  writing[i]£l) 

Example  6.  The  class  defined  above  has  one  drawback.  It  is  possible  for  a pro- 
cess to  use  the  class  unsafely  - for  example,  by  calling  read  without  having 
called  startread.  Such  a program  could  not  be  verified,  since  the  pre-condition 
of  read  requires  reading[caller] = 1 . It  would  be  better,  however,  if  unsafe 
actions  could  be  prevented  altogether.  The  class  pFile  implements  a protected 
file. 

type  pFile:  class 

begin  uFile:  rwfile; 

Initial;  true 

I:  V i E processid  (i  f caller  in  any  procedure  d 
reading[i]  = writing[i] = 0) 

procedure  pRead(i:  1 . .filesize;  var  x:  frecord); 

begin  uFile. startread;  uFile^read(i,x);  uFile. endread  end 
pRead.Pre:  true 
pRead.Post:  x = uFile.f[i] 
pRead.  Change  = <{) 

procedure  pWritp(i : 1 . .filesize; x:  frecord); 

begin  uFile. startwrite;  uFile.write(i  ,x);  uFile. endwrite  end 
pWrite.Pre:  true 
pWrite.Post:  uFile.f[i]  = x 
pWri te. Change = {uFile. f[i]} 

end  pFile 

The  class  uFile  is  declared  inside  pFile;  thus  its  procedures  are  not  access- 
ible outside  of  pFile.  Since  uFile  has  already  been  verified,  calls  to  its 
procedures  can  be  treated  as  elementary  actions  while  verifying  pFile.  Thus  the 
enter  and  exit  actions  are  elementary,  as  required.  Given  the  specifications 
of  uFile,  class  pFile  is  easy  to  verify. 

7.  TERMINATION 


Section  5 showed  how  class  procedures  can  be  treated  as  nondetermini  Stic  assign- 
ment statements  in  partial -correctness  proofs.  This  is  not  valid  for  termination 
proofs,  however.  For  example,  the  procedure  defined  by 

procedure  stop;  begin  wait(s) ; signal (s)  en^ 

is  equivalent  to  a null  statement  with  respect  to  partial  correctness,  but  not 
with  respect  to  termination.  To  deal  with  termination,  the  class  specifications 
must  be  extended  to  include  delay  assertions  giving  the  conditions  under  which 
each  procedure  may  fail  to  terminate.  To  prove  termination  for  a process  that 
calls  a class  procedure,  one  must  prove  that  the  procedure's  delay  condition  can 
not  remain  true. 
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When  the  cobegin  statement  was  introduced,  no  assumptions  were  made  about  the  im- 
plementation of  concurrency.  To  deal  with  termination,  however,  some  knowledge  of 
the  scheduling  rules  is  required.  Here  two  assumptions  are  made.  First,  the 
scheduler  is  fair;  i.e.  a process  proceeds  at  a non-zero  rate  unless  i t blocks,  exe- 
cuting wait(semdphore).  Second,  if  a process  is  blocked  at  wait(s),  it  must 
continue  after  a bounded  number  of  signal (s)  operations  have  been  performed. 
Thus  semaphore  scheduling  must  be  fair,  although  not  necessarily  first-come-first- 
served. 

The  proof  methodology  for  termination  is  essentially  that  of  Lamport  (1977);  it  is 
reviewed  informally  here.  The  basic  notion  is  a relation  A -*■  B (A  leads  to  B) 
between  sets  of  program  states. 

Definition.  Let  A and  B be  sets  of  states  for  a program  S.  Then  A -»  B iff 
a computation  which  reaches  a state  in  A must  eventually  reach  a state  in  B. 

Sets  of  program  states  will  be  described  by  assertions,  which  may  include  the 
predicates  start(i,L)  to  indicate  that  process  i is  ready  to  execute  the  state- 
ment labeled  L,  and  finish(i,L)  to  indicate  that  i has  just  finished  state- 
ment L. 

Formulas  like  A -*•  B are  proved  by  starting  with  a partial -correctness  proof  out- 
line for  the  program  S and  applying  axioms  and  inference  rules  for  termination. 
For  example, 

assignment  L:  x : = E legal  (E) 

( start (i ,L) A pre{L))^  (finish(i ,L) A post(L)) 

The  rules  for  other  sequential  statements  are  similar  and  will  not  be  given  here. 
For  concurrent  statements, 

cobegin  L:  cobegin  LiiSi //...//  Ln:Sn  coend 

start(i,Li)  finish(i  ,Li ) , for  l£i£n 
(start(0,L)  A pre(L))  -*•  (finish(0,L)  A post(L) ) 

signal  L:  signal (sem) 

(start(i ,L)Apre(L))  ■>  (finish(i ,L) A post(L) A sem = sem'  + 1 ) 

In  the  axiom  for  signal,  sem'  represents  the  value  of  sem  at  the  instant  when 
signal  began.  It  may  not  be  possible  to  deduce  sem=sem'+l  from  the  post- 
condition of  L,  since  that  assertion  must  be  interference-free.  However,  the 
state  sem  = sem'+l  must  occur,  even  though  it  may  not  persist,  and  this  is  re- 
flected in  the  axiom. 

The  rule  for  wait(sem)  is  harder  to  express,  since  wait  will  terminate  only  if 
other  processes  execute  a sufficient  number  of  signals. 

wait  L:  wait(sem) 


(start(i ,L) A pre(L) A sem  = 0)  > sem  > 0 

(start(i ,L) A pre(L))  ^ (finish(i ,L)  A post(i ,L)  A sem = sem' -1 ) 

In  order  to  prove  that  L:  wait(sem)  terminates,  one  must  show  that  the  semaphore 
sem  can  never  stay  at  zero  while  a process  is  waiting  at  L.  In  other  words, 
other  processes  are  guaranteed  to  perform  enough  signal  operations  to  allow  pro- 
cess i to  pass  L. 

The  termination  rule  for  a class  call  involves  its  delay  assertion.  C.p. Delay  is 
verified  by  pr>oving 


C.p.Delay-*' “'C.p. Relay  [-  start(body  of  p)  ->■  finish(body  of  p). 

In  other  words  C.p,  must  terminate  unless  the  condition  C.p. Delay  persists 
throughout  execution  of  C.p.  Once  C.p. Del  ay  has  been  verified,  the  following 
rule  can  be  used  to  prove  that  a call  to  C.p.  terminates. 

class  procedure  call  L:  C.p(a;e) 

(start(i ,L) A pre(L) A C.p.Delay)  > -«C.p. Delay 


(start(i ,L) A pre(L))  (finish(i ,L)  A post(L)  A C.p.post' ) 
where  C.p.post'  = C.p.post  ^ ^ cal^ler 

The  procedure  call  rule  has  the  same  form  as  the  semaphore  wait  rule.  In  fact, 
wait  and  signal  are  essentially  procedures  in  a pre-defined  class,  with 

sem. wait. Delay:  sem  = 0 

sem. signal .Delay:  false. 

The  examples  below  illustrate  verification  of  the  delay  clause  and  its  use  to 
prove  properties  related  to  termination. 

Example  1.  In  the  class  Counter  of  Section  3,  both  procedures  are  guaranteed  to 
terminate,  i.e. 

Counter. Add. Delay:  false 

Counter. Sub. Del  ay:  false 

The  delay  clause  is  verified  using  the  partial  correctness  proof  outline  in  Sec- 
tion 4.  Both  Counter. Add  and  Counter. Sub  have  the  form 

{m[caller]  = 0 A Counter. 1} 
a:  [wait(mutex);  m[caller]  := -1] 

{m[cal ler]  = -1  A Counter. I } 
sequential  statements 
b:  [signal  (mutex);  m[caller]:=  0] 

{m[cal 1 er]  = 0 A Counter. I } 

where  Counter.  I d ((mutex  = 1 -E  m[i])  A O^mutex^  1 ) 

(The  original  proof  outline  did  not  include  m[caller]  = 0 in  the  pre-condition  of 
the  wait  operation,  but  it  is  obviously  valid,  and  could  be  derived  formally  by 
adding  another  auxiliary  variable.) 

To  verify  the  delay  clause,  one  must  show 

false ->  -t  false  I- start(caller,a)  -►  finish(caller,b) 

|- start(caller,a)  ->•  finish(caller,b). 

The  sequential  operations  will  always  terminate,  as  will  b:  signal (mutex),  so  it 
is  only  necessary  to  show  that  a:  wait(mutex)  terminates.  From  the  proof  rule 
for  wait,  wait(mutex)  must  terminate  if 

(pre(a)  A mutex  = 0)  -►  mutex  > 0 

can  be  proved.  Now 

(pre(a)  A mutex  = 0)|-  (Counter.  I Am[caller]  = 0 A mutex  = 0) 

f-  3caller'(m[caller']  f OAcall  erf  caller'). 

Thus  some  process  caller'  is  in  the  sequential  part  of  Counter. Add  or 
Counter. Sub.  Eventually  caller'  will  execute  V(mutex),  leaving  mutex >0. 

Thus  (pre(a)  Amutex  = 0)  -*•  mutex  >0,  as  required,  and  the  delay  clause  Is  veri- 
fied. 


Example  2.  For  the  dynamically  allocated  resource  (Example  2 in  Section  6),  the 
delay  clauses  are 

Alloc. Acquire. Del  ay;  free  = empty 
Alloc. Release. Del  ay:  false 

Acquire  can  not  be  blocked  permanently  at  wait(mutex)  by  the  reasoning  used  a- 
bove.  It  can  be  blocked  forever  at  wait(freeCount)  only  if  the  condition 
freeCount = 0 remains  true.  Now  the  class  invariant  implies 

freeCount  = size (free)  + b - a. 

As  long  as  freeCount =0,  no  process  can  add  to  a,  and  a must  evencually  return 
to  0.  Thus 

freeCount  = 0 (a  = 0 V freeCount  > 0) . 

Combining  this  with  the  invariant  yields 

free  f empty  -*■  freeCount  > 0. 

Thus 

(free  = empty  ■>  freef  empty)  |-  (start(wait(freeCount) ) finish(wait(freeCount))) 
and 

( free  = empty -►  free  f empty)  |-  start(Acquire) ->finish(Acquire), 
ending  the  verification  of  the  delay  clause. 

To  verify  that  a call  to  Alloc. Acquire  terminates,  one  must  show  that 

free  = empty  ^ free  f empty 

in  the  program  which  uses  Alloc.  This  can  usually  be  accomplished  by  showing 
that  each  process  that  acquires  a resource  unit  will  eventually  release  it.  For 
example,  suppose  each  parallel  process  has  the  form 

begin  SI;  A1 loc. Acquire;  S2;  Alloc. Release  end 

where  SI  and  S2  do  not  contain  calls  to  Alloc. Acquire  or  Alloc. Release.  If 
S2  can  not  be  blocked, 

finish(i , Alloc. Acquire)  -►  finish(i , Alloc. Release) 

which  implies  that  the  set  of  free  units  can  not  remain  empty  forever.  If  SI 
can  not  be  blocked,  the  process  must  terminate,  and  if  all  processes  have  this 
form,  the  entire  cobegin  statement  must  terminate. 

In  many  applications,  concurrent  programs  are  intended  to  run  forever.  Termina- 
tion proofs  are  not  relevant  for  such  programs,  but  it  is  often  important  to  show 
that  a process  can  not  be  "starved,"  i.e.  permanently  blocked.  For  processes  with 
the  following  form: 

do  forever 

LI:  begin  SI;  Alloc. Acquire;  S2;  A1 loc. Release;  L2:  end, 
freedom  from  starvation  can  be  expressed  by 

start(i,Ll)  ->■  finish(  i ,L2) . 

By  the  same  reasoning  as  before,  the  processes  can  not  starve  if  SI  and  S2  can 
be  proved  to  terminate. 

Example  3.  The  first  solution  to  the  readers  and  writers  problem  (Courtois,  et  al., 
1971)  was  unfair  to  writers  in  the  sense  that  a stream  of  readers  could  keep  a 
writer  permanently  locked  out  of  the  file.  With  this  implementation,  the  delay 
clauses  for  the  class  rwfile  include 

rwfile. startread. Delay = false 

rwfile. startwrite. Delay  = max(reading[i ])  = 1 . 
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Proving  that  a process  calling  rwfile.startwrite  can  not  starve  requires  proving 
that  there  will  always  be  a time  when  no  readers  are  using  the  file.  Such  a proof 
would  be  impossible  for  most  programs.  In  general,  the  use  of  an  unfair  schedul- 
ing algorithm  makes  starvation  a real  possibility. 


8.  SUMMARY 


Any  proof  method  for  concurrent  programs  must  account  for  the  many  ways  that  ac- 
tions from  different  processes  can  be  interleaved  during  execution.  The  techniques 
described  in  Section  2 handle  such  interleaving  by  requiring  that  the  assertions 
used  in  proving  each  process  be  unaffected  by  the  actions  of  other  processes.  The 
proof  rule  for  shared  classes  (Section  5)  reduces  the  number  of  steps  in  this  in- 
terference test;  it  treats  a procedure  call  as  an  indivisible  non-deterministic 
assignment  statement.  Section  4 gives  the  rules  for  verifying  that  partial  cor- 
rectness is  preserved  under  this  transformation.  Although  information  about  ter- 
mination may  be  lost,  it  can  be  recovered  fromthe  delay  clause  in  the  procedure 
specifications.  Treating  procedure  calls  as  elementary  operations  simplifies  both 
partial -correctness  and  termination  proofs  by  decreasing  the  number  of  distinct 
actions  to  be  considered.  Proving  that  a class  meets  its  specifications  can  in 
principle  be  quite  complex,  because  of  the  interference  test.  In  most  cases,  how- 
ever, verification  is  relatively  simple  because  the  procedures  fall  into  one  of 
the  following  categories. 


1.  Procedures  provide  code  for  mutual  exclusion. 

2.  Procedures  do  not  modify  shared  data. 


3.  Procedures  operate  on  different  parts  of  the  shared  data. 

4.  Shared  data  is  dynamically  allocated  to  one  process  at  a time. 


In  these  cases  the  proofs  will  be  straightforward.  It  is  only  when  procedures 
simultaneously  operate  on  the  same  data  that  a detailed  interference  test  will  be 
required.  This  latter  kind  of  programming  is  in  general  so  difficult  and  unreli- 
able that  it  should  be  avoided  except  under  extreme  efficiency  constraints.  Most 
practical  applications  of  shared  data  classes  fall  into  one  or  more  of  the  classes 
above  and  so  are  not  hard  to  verify. 


The  proof  techniques  developed  in  this  paper  are  similar  in  spirit  to  the  reduc- 
tion method  (Lipton,  1974,  1976).  Reduction  also  simplifies  the  proof  of  parallel 
programs  by  allowing  a sequence  of  actions  to  be  treated  as  a unit.  The  two 
methods  differ  in  the  kinds  of  sequences  that  can  be  grouped  together,  the  means 
of  proving  that  a grouping  is  safe,  and  the  kinds  of  properties  that  are  preserved. 
In  reduction,  the  actions  to  be  combined  must  have  the  same  effect  in  all  execu- 
tions and  must  be  guaranteed  to  terminate  once  started.  Class  procedures,  on  the 
other  hand,  may  represent  non-deterministic  actions  and  may  fail  to  complete.  Re- 
ductions are  justified  by  proving  that  once  a sequence  is  started,  it  can  not  be 
blocked,  even  temporarily.  Usually  this  is  easier  than  proving  partial  correct- 
ness by  the  interference-free  method.  Reduction  preserves  both  the  values  com- 
puted by  a program  and  its  termination/deadlock  properties;  information  about  pro- 
cess starvation  may  be  lost.  The  class  procedure  rule  preserves  the  values  com- 
puted; termination  information  is  lost,  but  can  be  recovered  from  the  delay  asser- 
tion. Partial  correctness,  termination,  and  safety  from  deadlock  or  starvation 
can  be  proved  with  the  shared  class  techniques.  Lipton  presents  reduction  pri- 
marily as  a tool  for  proving  freedom  from  deadlock,  but  it  could  also  be  used  for 
partial  correctness  and  termination.  Overall,  the  conditions  for  applying  reduc- 
tion are  quite  strict,  and  the  class  procedure  rule  can  be  used  in  many  programs 
where  reduction  is  not  safe.  The  price  of  this  flexibility  is  the  potential  com- 
plexity in  proving  that  a class  meets  its  specifications.  When  both  methods  ap- 
ply, reduction  is  likely  to  give  an  easier  proof. 


Monitors  are  a special  case  of  shared  classes;  their  semantics  are  such  that  moni- 
tor procedures  may  always  be  considered  elementary.  Silberschatz,  et  al.,  (1977) 
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propose  extending  concurrent  Pascal  (Brinch  Hansen,  1975)  with  a new  type,  the  dy- 
namically-managed class.  This  is  another  instance  in  which  easier  proof  rules  ap- 
ply. A fruitful  extension  of  this  work  would  be  the  application  of  the  general 
proof  rule  to  derive  simpler  rules  for  important  special  cases. 
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APPENDIX 


In  this  appendix,  the  class  procedure  call  rule  of  Section  5 is  justified  by  show- 
ing that  it  can  be  derived  from  the  other  axioms  and  inference  rules. 

Theorem.  Suppose  that  C is  a class  in  a program  S,  where  procedures  of  C 
are  called  only  from  the  processes  of  S and  not  from  other_classes.  Let  S'  be 
the  program  obtained  from  S by  replacing  each  call  C.p(a;  e)  of  a class  proce- 
dure C.p.(varx,y)  by 

begin  x :=5';  ^;=¥;  body  of  C.p;¥  :=  x end. 

Then  if  {P}S{Q}  can  be  proved,  {P}S'{q}  can  also  be  proved. 

Repeated  application  of  this  theorem  can  be  used  to  remove  all  class  calls,  be- 
cause there  is  no  cycle  of  classes  which  call  each  other.  (If  S had  such  a 
cycle,  {P}S{Q)  could  not  be  proved,  since  all  classes  called  by  C must  be 
verified  before  C). 

Before  sketching  a proof  of  the  theorem,  we  review  the  structure  of  class  proce- 
dures and  define  some  names  for  assertions  and  sets  of  variables.  Recall  that  the 
variables  of  C can  be  partitioned  into  data  and  control  variables:  let  C.c 
name  the  set  of  control  variables  and  C.d  the  data  variables.  Each  procedure 
C.p  has  the  form 

begin  declarations;  enter;  operate;  exit  end, 

where  enter  and  exit  are  elementary  actions  on  C.c  and  operate  is  composed 
of  elementary  actions  on  C.d.  A proof  outline  for  C.p  has  the  form 
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C.p.  (var  x,y) : {p.preAI} 
p. enter; 

{p. entered} 
p. operate; 
{p. leaving} 
p.exit; 
{p.post  A I } 


where  the  program  variables  free  in  p.pre  and  p.post  are  from  C.d.,  x,  or  y, 
and  the  other  assertions  may  have  free  variables  from  C.c.  in  addition.  We  will 
require  p.pre = 3C.c{p. entered) , i.e.  p.pre  is  equivalent  to  p. entered  with 
respect  to  variables  in  C.d.  Such  a choice  for  p.pre  is  legitimate  for  the 
proof  outl ine,  since  p. enter  is  independent  of  the  variables  in  C.d.  Likewise, 
we  require  3C. d(p. entered)  = 3C.d{P) , for  each  assertion  P from  p. entered  to 
p. leaving,  i.e.  p. entered  and  P agree  on  C.c.  Again,  this  is  legitimate, 
since  p. operate  is  independent  of  C.c.  Recall  that  each  assertion  in  the  proof 
outline,  except  the  first  and  last,  is  invariant  over  all  actions  in  class  proce- 
dures. 

In  order  to  prove  the  theorem,  we  must  show  how  to  derive  a proof  for  P{S'}Q, 
given  one  for  P{S}Q.  The  approach  will  be  to  define  a tranformation  M on  the 
assertions  in  a proof  of  S such  that,  for  each  statement  T in  S, 

{P}T{Q}  I-  {M(P)}T’{M(Q)}. 

A simple  choice  for  M(P)  is  P itself.  This  would  be  adequate  for  the  sequen- 
tial proof,  but  in  general  it  will  not  pass  the  interference  test.  This  is  be- 
cause the  grain  of  action  in  S is  the  class  procedure,  while  in  S'  it  is  the 
elementary  action  within  the  procedure.  Even  though  P was  interference-free  in 
S,  it  may  not  be  in  S'.  Thus,  M(P)  must  be  a weaker  assertion  than  P itself. 
Now  if  M(pre(S))  implies  that  the  variables  accessed  by  S are  in  a state  con- 
sistent with  pre(S),  executing  S will  result  in  a state  in  which  those  vari- 
ables are  consistent  with  post(S),  regardless  of  the  values  of  other  variables. 
The  syntax  of  shared  classes  allows  S'  to  be  partitioned  into  three  kinds  of 
statements,  which  use  disjoint  sets  of  variables. 

{Tl}main  program  neither  C.c  nor  C.d 

{T2}  p. enter, p.exit  C.c. 

{T3}  p. operate  C.d 

(This  is  a slight  oversimplification  - the  main  program  may  call  a class  which  is 
also  called  in  C,  so  that  its  variables  are  in  either  C.c  or  C.d.  Step  5 in 
the  interference  test  for  verifying  C assures  that  this  will  do  no  harm). 

For  a statement  T1  in  the  main  program,  M(pre(Tl))  will  imply  that  all  non- 
class variables  are  in  a state  consistent  with  pre(Tl),  and  that  if  all  pro- 
cesses were  to  finish  executing  class  procedures,  pre(Tl)  would  hold  in  the  re- 
sulting state.  The  assertion  WH(P,Acti ve) , defined  below,  essentially  states  that 
P would  hold  if  all  processes  left  the  class.  Let 

Active=  {v:  process  v is  executing  a class  procedure  in[v]}; 

(Active  and  in  are  auxiliary  variables  in  S').  Then 

WH(P,V)  = Va((  A in[v].post  3 P) 
veV 

where  a = u (in[v]. Change  uvar  parameters  of  in[v]). 

Note  that  WH(pre(Tl ), Active)  implies  that  non-class  variables  are  in  a state 
consistent  with  pre(Tl),  so  T1  executes  exactly  as  it  would  if  pre(Tl)  were 
true.  The  only  exception  is  at  a procedure  call  T = C.p(a,e)  in  S,  which 
is  started  by  p. enter  in  S'.  In  the  proof  of  S,  the  class  call  rule  was  used 
to  verify  T,  so 

pre(T)  f-3k(p.preA  VT  (p.postDpost(T))) 
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(The  substitution  of  actual  parameters  is  ignored  here,  since  it  is  covered  by  as- 
signment statements  in  S'.  Also,  we  can  add  an  auxiliary  variable  to  record  the 
values  of  k which  satisfy  the  assertion;  this  makes  it  possible  to  remove  3k 
from  the  assertions.) 

Now  if  WH(pre(T),Active)  holds  before  class  entry,  then  WH(post{T) , Active)  will 
hold  after  entry,  because  the  process  executing  enter  joins  the  active  set. 
WH(post(T), Active)  remains  true  throughout  the  class  body,  because  all  variables 
which  can  be  modihed  by  C.p  are  quantified  in  WH(post(T) , Active) . So  just  be- 
fore p.exit,  WH(post(T), Active)  holds;  also  p. leaving  holds  (this  will  be 
proved  shortly).  Since  p. leaving  [-  p.post,  and  p.post A WH(post(T),Active) 
o WH(post(T), Active''- {v}),  WH(post(T), Active)  must  hold  after  exit.  Thus, 
letting  pre{T ') e WH(pre(T) .Active)  is  sequentially  valid.  It  is  also  inter- 
ference-free: the  quantifiers  prevent  actions  in  the  class  procedures  from  affect- 
ing WH(pre(T) .Active) , and  pre(T)  is  invariant  over  actions  of  other  processes 
outside  C. 

For  actions  in  procedure  C.p  to  perform  correctly,  it  is  sufficient  that 
C.p.pre  hold  on  entry.  If  T is  a call  to  C.p.(a’,®')  in  S,  we  know  that 
WH(pre{T))  holds  before  entry,  and  pre(T)  (-  p.pre.  But  we  need  to  know  that 
p.pre,  not  just  WH(p.pre),  holds  after  p. enter.  This  can  be  proved  by  adding 
the  assertion  A WHB(pre(T),Active,r)  to  M(pre(T)).  WHB(pre(T) .Active, r) 
r e procedures 

essentially  states  that  if  pre(T)  (- r.pre  (which  is  always  true  when  T is  a 
call  to  C.r),  then  r.pre  would  hold  if  all  procedures  which  car,  block  r would 
finish. 

To  express  WHB(pre(T),Active,r),  we  need  to  consider  the  circumstances  under 
which  procedure  C.r  can  be  entered.  Since  r. enter  uses  only  control  variables, 
C.r  can  be  entered  unless  some  C.q  has  set  the  control  variables  to  lock  out 
C.r.  Procedures  r and  q are  said  to  lock  (lock(r,q))  if  there  is  no  control 
state  consistent  with  both  of  them  being  in  execution. 

The  proof  of  C showed  that  C.r  and  C.q  are  interference-free.  Because  there 
is  no  interaction  between  the  enter/ exit  actions  and  the  operate  section,  it  can 
be  proved  that  the  non-interference  comes  about  in  one  of  two  ways 

1)  lock(q,r):  C.q  and  C.r  can  not  be  in  execution  at  the  same  time 

2)  -ilock(q,r):  the  non-interference  test  involved  no  knowledge  of  the 
state  of  control  variables.  Thus  for  T an  action  in  p.q,  if 
C.r  does  not  interfere  with  pre(T)  then  C.r  does  not  interfere 
with  3C.c(pre(T)).  In  particular,  C.r  does  not  interfere  with  p.pre. 

Returning  to  the  assertion  WHB(pre(T) ,Active,r) , if  pre(T)  (-  r.pre,  then 
WHB(pre(T)  ,r)  should  guarantee  that  r.pre  would  hold  if  procedure  C.r  wereentered. 
Now  any  procedure  C.q  which  can  falsify  r.pre  must  satisfy  lock(r.q),  so  C.r 
can  not  pass  r. enter  while  C.q  is  in  execution.  Now  WH(pre(T))  means  that 
pre(T)  would  hold  if  all  processes  left  class  procedures.  But  r.pre  would  hold 
if  all  procedures  which  block  r were  inactive,  since  the  other  procedures  do  not 
falsify  r.pre.  This  gives  the  formula  for  WHB(pre(T), Active, r): 

WHB(pre(T) , Active, r)  = V variables(pre(T)3r.pre)3WH(r.pre.rBlock), 

where  rBlock  = Activeu{q:  block(r,q)} 

The  final  form  of  the  transformation  M(P),  for  an  assertion  P in  process  v,  not 
in  a class  body,  is 

WH(P, Active)  A V r (WHB(P,Active,r))  A C.I  A in[v]  = null  A v Active 

For  an  assertion  P in  the  body  of  C.p  in  process  v,  where  Q is  the  post- 
condition of  the  call  of  C.p,  M(P)  is 

WH(Q, Active)  A V r (WHB(Q, Active, r))  A P A in[v]  = C.p  A v e Active 
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A formal  proof  that  M yields  a valid  proof  for  S'  can  be  accomplished  by  using 
induction  on  the  structure  of  statements  T in  S,  to  shov/  that 

{pre(T)}T{post(T)}  |-  {M(pre(T))}T' {M(post(T))}. 

The  proof  is  not  given  here;  it  primarily  involves  manipulation  of  logical  formu- 
lae. Hopefully,  the  reader  is  satisfied  with  the  informal  arguments  for  sequen- 
tial validity.  Non-interference  for  WH  has  been  discussed;  non-interference 
for  WHB  is  similar.  The  only  difference  is  that  actions  in  C.q  with  -,lock{r,q) 
can  modify  variables  in  r.pre  without  invalidating  r.pre,  so  those  variables 
do  not  have  to  be  quantified  in  WHB.  Finally,  for  T in  a class  procedure, 
pre(T)  must  be  invariant  over  actions  in  C,  and  actions  outside  C can  not  af- 
fect its  variables. 
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